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Transmission of MPEG2 transport stream packets over IP 



Why is it important now. 

Transmission of data packets over the Internet is applied very often. However the Internet 
is a packet switched network, which means that every packet is transmitted independently 
ftom the other packets, there is in general no guarantee that the IP packets arrive after a 
5 certain time. Every packet will have a different delay, even the order of the packets at the 
receiver might have been changed. 

For Real-Time applications this is a problem, here the order of the packets should be kept 
the same and all packets should have, within a certain tolerance, the same overall delay. 
An example of a Real-Time application is Transmission of MPEG encoded Audio and 
10 Video (e.g. Video-On-Demand) signals. The Real-Time applications are getting more and 
more important. 

Existing situations 

There has been standardized for the WWW a Real-Time Protocol (RPC1889). In 
15 RFC1S89 there are two different data packets: 

■ RTP: A Transport Protocol for Real-Time Applications. In these packets the data 
packets which carry the real-time properties are transmitted. 

■ RTCP: RTP Control Protocol, which is used to monitor the quality of service and to 
convey information about the participants in an on-going session. In the RTCP it is 

20 possible to transmit both (he RTP timestamp and the NPT. The NPT is the wall clock 

(the same all over the world). It is optional to implement an NPT at the receiver 
However RFC1889 cannot be used on its own, an additional protocol is needed for a 
certain application. For the transmission of MPEG data, the additional protocol 
(RFC2250) must be applied. Standard$2ation of RFC2250 is not yet (completely).iinished. . 

25 

Problems with the existing situation, 
a In RFC1889 a header is added to every IP packet. The header contains a time-stamp 
which is derived from the clock used in the application. The contents of the timestamp is 
30 specified in KPC2250 (or any other application protocol if another application is 
transmitted). In RPC2250 the timestamp is derived from the 27 MHz clock used in 
MPEG- The resolution is -1 1 msec (90 kHz clock) which is not sufficient for MPEG 
Transport streams. The timestamp with the higher resolution is in the TS packet itself (the 
PGR packet). 

35 a Also in an IP transmission this 27 MHz clock j&equency (and phase) cannot be 

transmitted, the receiving clock should be locked with a PLL to the transmitter clock. 

This is very difficult if the jitter on the packets is very large, 
a If the transmission delay is not known then the buffer size needed to compensate the 

jitter introduced by the network, is doubled. The jitter on the Internet can be large so the 
40 size of the buffer will be large. Also the overall delay is larger than needed (up to two 

times). 

a To increase the efficiency of the packing, a number of TS packets is packed in one IP 
packet There is only one RFC1 889 timestamp for the whole IP packet This timestamp 
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refers to the first TS packet of the IP packet. The jitter on the applications packets which 
are packed in one IP packet is still remarkable (too hi$i for MPEG). Jitter compensation 
for every individual T$ packet is needed, 
a The MPEG2 Transport Stream is not the only Real-time application. Other applications 
5 are e.g.: 

■ Transmitting DV packets over IP 

■ Transmitting IBC958 audio packets over IP 

■ Transmitting DSS packets over IP. 
For these applications there is protocol yet 

10 

Proposal: 

□ Using a Timestamp in the RFC1 889 which is derived from a clock known in both the 
transmitter and the receiver. Then the transmission delay is known on receiving side. In 
15 this way the receiver buffer size (and delay) can be minimized. 

a Packing of the MPEG TS packets in such a way in the IP packet that the remaining jitter 
on the TS packets can be compensated. 

In the following some embodiments of the proposal are given. 

20 

Embodiment 1: Using modified RFC18S9 protocol 

Transmit in the RTP packet header the NPT timestamp (see figure 1). TheRTP 
timestamp is not derived from the clock used in the application but from the wall clock in 
the transmitter. The RTP time stamp represents the NPT value (at the transmitter) at the 

25 moment the first byte of the IP packet is delivered to the transmitter. 

The wall clocks at the Transmitter and at the Receiver do have the same counter value. 
The delay from the RTP packet can be calculated by comparing the NPT time stamp with 
the NPT value of the receiver wall clock. A maximum overall delay should be realized. 
The delay during transmission is known, the remaining required delay in the receiver 

3 0 buffer can be calculated (overall delay minus delay during transmission). Once the delay 
of the first packet is set, then the delay of the other packets can be calculated. The size of 
the buffer is equal to [maximum bit rate * maximumdelay of the packets]. 

In figure 2 it is explained how the constant delay is made. A variable input rate is (with a 
35 Peak-rate equal to the maximum rate) expected. The constant overall delay consists of a 
contribution from the transmitter and a contribution realized in the receiving buffer. The 
delays cannot be negative (lines A-B-C do not cross each other). 

If the wall clock is not implemented in the receiver then the NPT counter is set to the 
40 value of the first RTP timestamp (expecting minimum delay in the transmission), The first 
packet is removed from the buffer after a time which is equal to the maximum delay in the 
transmission. Once the delay of the first packet is set, then the delay of the other packets 
can be calculated. The buffer si2e in the receiver is should be at least twice the (maximum 
bit rate * ^yiminn delay of the packets). Expecting a maximum bit rate of 2 Mbyte/sec 
45 and a maximum delay of 1 second then a buffer size of 2 Mbyte can be saved by 
implementing the NPT wall clock. 

The compensation of the jitter from the MPEG TS packets in the IP packet is explained m 
embodiments 3 and 4, 

The advantage of tins system w.r.t the current situation, are: 
50 ■ The application layer is de-coupled from the transmission. The method can be used for 
other applications too (like DV, DSS, IEC958). 
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■ The buffer size and the delay can be minfmiz^ed by iiiiplemeiiliDtg the wall clock at the 
receiver. 

5 Embodiment 2: Minimizing the buffer size while using the existing protocols. 

Transmit in the RTP header a timestamp which is derived from the clock used in the 
application For MPEG Transport Streams this is specified in KFC2250. Transmit in a 
RTCP packet an RTP timestamp which is derived from the dock of the application and 
an NPT timestamp derived from the transmitter wall clock. Both timestamps refer to the 
10 same moment in time. If the receiver implements the NPT wall clock then the buffer size 
can be reduced, This is explained in figure 3. 

At the transmitter a number of MPEG TS packets are packed in one IP packet. Hie RTP 
timestamp is derived from the S TC counter, the value of the timestamp corresponds to the 
arrival time of the first byte of the first TS packet in the IP packet. 
15 At regular instances an RTCP packet is interleaved between the RTP packets. The RTCP 
packets contains an NTP timestamp and an STC timestamp. Both timestamps are derived 
at the same moment 

On the receiving side The NPT timestamp is compared with the Wall clock from the 
receiver. The Transmission delay of the RTCP packet is known. Now the STC counter can 

20 be set to the correct value (same value as in the transmitter). The STC counter and the 
RTP timestamps are used to compensate the jitter of the IP packets. A maximum overall 
delay is expected* The delay during transmission is known, the remaining delay in the 
buffer can be calculated (overall delay minus delay during transmission). The size of the 
buffer is equal to [maximum bit rate * maximum delay of the packets]. 

25 The advantages of this system are: Existing protocols can be used. It is a manufacturers 
option to implement the Wall clock at the receiver. If the wall clock is not implemented 
then the STC counter is set to the value of the first RTP timestamp (expecting minimum 
delay in the transmission).. The first packet is removed from the buffer after a time which 
is equal to the maximum delay in the transmission. The buffer size in the receiver is 

30 should be at least twice the (maximum bit rate * maximum delay of the packets). 

The compensation of the jitter from the MPEG TS packets in the IP packet is explained in 
embodiment 3 and A 

A remaining disadvantage is that only the MPEG TS transmission is standardized. Real- 
time protocols like RFC2250 for MPEG ara not yet available for other Real-time streams ( 
35 DV,DSS,IBC958). 

Once the jitter is compensated from the IP packets then still the jitter from the individual 
packets in one IP packet should be compensated. For understanding the timing of 
Transport Stream packets from a "Pull" and a "Partial 11 Transport stream are given in 
40 figure 4. Packing a number Transport stream packets is shown in Figure 5. 



Embodiments: Jitter compensation of the MPEG TS packets using an additional time 
stamp. 

45 If the maximum size of an IP packet is limited to 1500 bytes then a m a ritmtm of 7 TS 
packets can be packed in one IP packet The IP packets are still aligned with the MPEG 
TS packets, although this is not needed in this proposal. The method applied for 
transmitting MPEG Transport streams over Digital Interfaces is applied. To every TS 
packet a time stamp is added which contains the arrival time of the TS packet . The time 

50 stamp is derived from the STC clock (27 MHz) which is used in the MPEG2 TS. In this 
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way S ource packets with a size of 1 92 bytes are created Up to 7 S ourc e packets are 

packed in one IP packet. Some examples are given in Figure 5* 

It is expected that with the embodiments 1 or 2 the jitter of the IP packets is removed. 

5 In figure 6 the method for compensating the jitter on the individual packets is shown for 
the situation where embodiment X is used to compensate the jitter on the IP packets. In 
the buffer [B2] the jitter introduced by packing 7 (or less) Source packets in one IP 
packet, is compensated. The size of buffer [B2] is small ( 1 or 2 IP packets). 

10 La figure 7 the method for compensating the jitter on the individual packets is shown for 
the situation where embodiment 2 is used to compensate the jitter on the IP packets. Now 
there is needed only one buffer . 

The advantage of this method (using an additional time stamp for every TS packet) is that 
15 it is also simple for Partial TSs. 



Embodiment 4: Jitter compensation of Hie MPEG TS packets. No additional time stamp is 
wed. 

20 Again the maximum size of an IP packet is limited to 1500 bytes, a maximum of 7 TS 
packets can be packed in one IP packet. The IP packets are still aligned wife the MPEG 
TS packets, although this is not needed in this proposal. Up to 7 Source packets are 
packed in one IP packet Some examples are given in Figure 5. 
It is expected that with the embodiments 1 or 2 the jitter of the IP packets is removed. 

25 

In figure 8 the method for compensating the jitter on the individual packets is shown for 
the situation where embodiment 1 is used to compensate the jitter on the IP packets. In 
the Receiver the STC counter is locked to the PGR in the MPEG TS* For this purpose it is 
best to have as less as possible jitter on the arrival time of the PGR- The PGR packet 
30 should be the first of the packets in the IP packet 

hi the buffer [B2] the jitter introduced by packing 7 (or less) TS packets in one IP packet/ 
is compensated. There is a difference in the implementation for the "foil 1 TS and the 
'partial' TS. 

35 For restoring a Pull TS, all the packets between two PCFjs axe stored in Buffer [B2]. Then 
the packets are equally distributed over the interval between the two PCR values. For this 
method the buffer [B2] needs to be quite large (a few hundred kByte). 

For restoring a Partial TS the following is carried out 
40 The jitter on the PGR packets is removed in the normal way (using the timestamp of the 
PCR packet). The contents of the Video, audio and systems buffers is simulated. Every 
next packet is removed from die buffer [B2] as soon as it is allowed by the buffer 
constraints* 
Note: 

45 = The order of the packets has not been changed Only one packet at a time needs to 

be considered. 

= The resulting stream might have gaps just before the PCR packet, but this is 
allowed for partial Transport streams. 



50 
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In figure 9 the method for compensating the jitter on the individual packets is shown for 
the situation where embodiment 2 is used to compensate the jitter on the IP packets. Now 
there is needed only one buffer . . There is a difference in the implementation for the 
"full 1 TS and the 'partial' TS. 

For restoring a Full TS, all the packets between two PCRs are stored in Buffer [Bl+2], 
Then the packets are equally distributed over the interval between the two PGR values. 
For this method the buffer needs to be larger (a few hundred kByte). 

10 For restoring a Partial T$ the following is carried out 

The jitter on the PCR packets is removed in the normal way (using the timestamp of the 
PGR packet). The contents of the Video, audio and systems buffers is simulated. Every 
next packet is removed from the buffer [B2] as soon as it is allowed by the buffer 
constraints. 



15 



Note: 



= The order of the packets has not been changed. Only one packet at a time needs to 
be considered. 




allowed for partial Transport streams. 
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Claims: 



10 



15 



20 



25 



30 



[1] = A method to transmit in the RTP protocol a time stamp which is independent from 
the clock frequency. The time stamp is derived from the wall clock at the 
transmitter. 

- The 32 bits from the 64 bit NPT counter are selected in such a way that the 
resolution is high enough for accurate jitter compensation, and the maximum 
interval is larger than the maximum jitter on the IP packets. 

—A method to minimize the buffer size and Hie delay on receiver side while using 
this time stamp. 

= A method to minimize the buffer size and the delay on receiver side if the wall 
clock is not present in the receiver. 

[2] = Using the RTCP protocol in such a way that the buffer size and the delay in the 

receiver is minimized. 
= Rep eating transmission of the RTCP packets in such a way that differences in time 

base between NPT clock and STC clock can be compensated. 
= Checking the long t erm average amount of data in the buffer in order to discover 

difference in time base between NPT clock and STC clock. 

[3] « Inserting a time stamp which is derived from the clock used in the application 
before every application packet Using Hie time stamp from every first application 
packet of an IP packet (after DP packet jitter compensation) as the reference signal 
for the PLL on the receiver side. 

[4] ■ Packing the MPEG TS packets in IP packets in such a way that the PGR packets axe 
always the first TS packet in the IP packet 

[S] = Restoring a Full MPEG TS by storing all packets between two PGR packets and 
equally distributing these packets on the time axis between the two PGR values on 
the time axis. 

• [6J Restoring-a partial MPEG T& by putting the PGR packets on the time axis indicated — 
by the PGR value and by simulating the contents of decoder / transmitting buffers 
and putting the non-PCR packets in such a way and one-by-one on the time axis, 
that no violation of the buffer constraints occurs. 
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Figure-l: Block diagram of Transmitter / Receiver using modified RFC18S9 . 

STC = System Time Clock (time base of the MPEG coder), derived from 27 



MHz clock 



PCR » Program Clock E^ference (resolution one period of the 27 MHz clock) 

NPT counter contains 64 bits. 

b(X.b3 1 for the fraction of a second, 

b32„b63 for the number of seconds 

The RTP time stamp is 3 2 bits long . The accuracy is enough to realize a small 
IP packet jitter after Jitter compensation. This depends on the maximum jitter 
which can still be compensated in the jitter compensation of the MPEG 
packets. The maximum tolerance for MPEG packets is 500 nseo. 
The Wrap-around in the 32 bit counter value should be larger than the 
maximum delay of the IP packets. Expecting a maximum delay of 1 second, 
then e.g. 

RTP time stamp is blO .. b41 of the NPT counter fulfils all requirements. 



A3. JUL--£1KR3C. XJ'CXD ^Bf- 

PHNL020721EPP 



1 □ « ■ saw i a m i urJL 

014 19.07.2002 13:30 



19.07.2002 



10 



15 



20 



Cumulative 
amount of bytes 



1 



Output from receiver 
Input to receiver 
Input to transmitter 




fims 

figure 2: Cumulative amount of bytes as a function of time. 

A 5=5 Input to the transmitter 
B » Input to the receiver. 
C = Output from the receiver. 
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Figure-3; Block diagram of Transmitter / Receiver using the RFC1889 with RTCP 
packets* 

The RTP time stamp is 32 bits. The PCR is 42 bits (STC base + STC extension). 
So the range of the RTP time stamp is less then the range from the PCR 

r. TheRTPtime stamp is derived from a 90 kHz clock, STC-base [RTP-timestamp^ 

is b9..b40 from the PCR]. 

The NPT timestamp hi the RTCP packet is the mil 64 bits and the RTP 
timestamp is again 32 bits (same as in RTP packet). 

Note: 

■ The accuracy from the RTP timestamp should be large enough to have a 
small enough jitter from the IP packet (small enough to compensate jitter of 
the individual TS packets from the IP packet). The warp-around should 
represent a large enough time interval (larger than the maximum delay of the 
IP packet). 

■ The STC counter (on Record side) might drift away from me NPT counter. 
On the receiver side at regular instances RTCP packets must be used to 
check and if needed the STC counter value should be adjusted. 
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Figure 4a: MPEG TS packets from a fall Transport Stream -with variable bit rate. 
'** this example the Transport Stream contains only one PCR PID number. 

In 1EC13818-1 it is specified the bit rate between two PCR packets is 
constant. Variable bit rate is realized by making a piece-wise constant bit 
rate. The distance between PCR packets is < 100 msec (very often < 40 
msec). "With a bit rate of 2 Mbyte/second mere are 200 kbytes between two 
PCR packets if the distance is 100 msec and there are 80 kbytes if the 
distance is 40 msec. 
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Figure 4b: MPEG TS packets from a partial Transport Stream with variable bit 

In this example the Transport Stream contains only one PCR PID number. 
In D5C6I883-4 the partial Transport stream is explained. The bit rate need 
not be constant between two PCR values. The buffer constraints from the 
STD model are still fulfilled. 
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10 Figure Sa: Packing a number of MPEG TS packets in one IP packet. 

There axe no constraints location of the PCR packet in the IP packet. 



15 



Minn nnn n nun n n nnn n 

\\ N 
\ \ \ \ X 

1 1 n ii j rm bxjx3 

IP packet IP packet 



20 



Figure 5b: Packing a number of MPEG TS packets in one IT packet, PCR packets 
25 are aligned. 

If there is aPCR packet in the IP packet, then it is the first of the packets in the 
IP packet 

The number of TS packets between two PCR packets is 200 1000 for a 2 
Mbyte/second bit rate. Efficiency is of packing reduced only a little if aligning 
30 of PCR packets is applied. 
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Figore-6: Block diagram of Transmitter -AReceiver using modified -BFG1889. • 
to Buffer JBl] is used to compensate the jitter on fee IP packet?. 

Buffer [B2] is used to compensate the jitter on the individual TS packets in a IP 

SSe Receiver the STC counter is locked to the PCR in the MPEG TS. For this 

purpose it is best to have as less as possible jitter on the arrival time of the PCR. 

The PCR packet should he the first of the packets in the IP packet 

The timestamp in front of the TS packet is used to compensate the jitter. The 

size of the buffer |B2] is a few JP packets. 

Notei * 

After compensation of the IP packet jitter! the time stamp from the first TS 
packet of every IP packet can be used as input for the PLL. There are much 
more IP packets man PCR packets, so PLL is more stable. 



PHNL020721EPP 



i H » • mm m mm i i »a 

019 19.07.2002 13:33 



10 



15 



20 



25 



13 



MPEG2TS 



188 byte 
TS packets 



Inserting 
Time stamp 



PGR 



292 byte 



Source packets 



Coxnpcnsation. of 
jitter on MPEG2 
TS packets 
[Bl+2] 



1 


r 


v 


STCPLL 




Creating IP 


(27 MHz) 




packet payload 



STC 



RTP 
Timestamp 



Burst of 192 byte 
! pucket^^ 



RTP 

packet 



19.07.2002 



288 byte 
TS packets 



Set STC 
counter 



RTP 




RTCP 




— * 


packet 



Wall clock 
NPT 



NPT 
Timestamp 




Transmitter ->U — Receiver 



30 Rgttre-7: Block diagram of Transmitter / Receiver using the RFC1889 with RTCP 
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On the Receiver there is noPLL. ■ ........ 

The time stamp in front of every Ts packet is used to compensate the jitter of each 

TS packet 
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Transmitter —►-J -4 — Receiver 

Figure-S: Block diagram of Transmitter / Receiver using modified R1FC1889 - 

Buffer [B 1] is used to compensate the jitter on the IP packets. 

Buffer £B2] is used to compensate the jitter on the individual TS packets in a IP 

r -packet.* 5— v-v— — . • =■ < — ™» • 

In the Receiver me STC counter is locked to the PCR in the MPEG TS. For this 
purpose it is hest to have as less as possible jitter on the arrival time of the PCR 
The PCR packet should be the first of the packets in the IP packet. 

For restoring a Full TS ? all the packets between two PCRs are stored in Buffer 
[B2]. Then the packets are equally distributed over the interval between tiae two 
PCR values. For this method the buffer JB2] needs to be quite large (a few 
hundred kByte). 

For restoring a Partial TS the following is carried out 
The jitter on the PCR packets is removed in the normal way (using the 
timestainp of the PCR packet). The contents of the Video* audio and systems 
buffers is simulated. Every next packet is removed from the buffer [B2] as soon 
as it is allowed by the buffer constraints. 

Note:= The order of the packets has not been changed. Only one packet at a 
time needs to be considered, 
= The resulting stream might have gaps just before the PCR packet, but 
this is allowed for partial Transport streams. 
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30 Blgure-9: Block diagram of Transmitter / Receiver using the RFC 1889 with RTCP 
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On the Receiver ftiere is no ELL, but RTGP packets aire needed at tegular distances 
(or the average content of the buffer should be kept constant). 

For restoring a Full TS, all the packets between two PCRs are stored in Buffer 
JB1+2]- Then the packets are equally distributed over the interval between the 
two PCR values. For this method the buffer needs to be quite large (a few 
hundred kByte). 

For restoring a Partial TS the following is carried out 
The jitter on the PGR packets is removed in the normal way (using the 
timestamp of the PCR packet). The contents of the Video, audio and systems . 
buffers is simulated. Every next packet is removed from the buffer [B2] as soon 
as it is allowed by the buffer constraints. 

Note: 53 The order of the packets has not been changed. Only one packet at a 
time needs to be considered* 
~ The resulting stream might have gaps just before the PCR packet, but 
this is allowed for partial Transport streams. 
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